Aides d'itérateur JavaScript et exécution parallèle : une immersion dans le traitement de flux concurrent

Dans le paysage en constante évolution du développement web, la performance n'est pas seulement une fonctionnalité ; c'est une exigence fondamentale. À mesure que les applications traitent des ensembles de données de plus en plus massifs et des opérations complexes, la nature traditionnelle et séquentielle de JavaScript peut devenir un goulot d'étranglement important. De la récupération de milliers d'enregistrements depuis une API au traitement de fichiers volumineux, la capacité à effectuer des tâches de manière concurrente est primordiale.

C'est là qu'intervient la proposition des Aides d'itérateur (Iterator Helpers), une proposition du TC39 au stade 3, prête à révolutionner la façon dont les développeurs travaillent avec les données itérables en JavaScript. Bien que son objectif principal soit de fournir une API riche et chaînable pour les itérateurs (similaire à ce que `Array.prototype` offre pour les tableaux), sa synergie avec les opérations asynchrones ouvre une nouvelle frontière : le traitement de flux concurrent, élégant, efficace et natif.

Cet article vous guidera à travers le paradigme de l'exécution parallèle à l'aide des aides d'itérateur asynchrones. Nous explorerons le 'pourquoi', le 'comment' et les 'prochaines étapes', vous fournissant les connaissances nécessaires pour construire des pipelines de traitement de données plus rapides et plus résilients en JavaScript moderne.

Le goulot d'étranglement : la nature séquentielle de l'itération

Avant de plonger dans la solution, établissons fermement le problème. Prenons un scénario courant : vous avez une liste d'ID d'utilisateurs, et pour chaque ID, vous devez récupérer les données détaillées de l'utilisateur depuis une API.

Une approche traditionnelle utilisant une boucle `for...of` avec `async/await` semble propre et lisible, mais elle cache un défaut de performance.

            
async function fetchUserDetailsSequentially(userIds) {
  const userDetails = [];
  console.time("Sequential Fetch");

  for (const id of userIds) {
    // Chaque 'await' met en pause toute la boucle jusqu'à ce que la promesse soit résolue.
    const response = await fetch(`https://api.example.com/users/${id}`);
    const user = await response.json();
    userDetails.push(user);
    console.log(`Fetched user ${id}`);
  }

  console.timeEnd("Sequential Fetch");
  return userDetails;
}

const ids = [1, 2, 3, 4, 5];
// Si chaque appel API prend 1 seconde, cette fonction entière prendra environ 5 secondes.
fetchUserDetailsSequentially(ids);

            

              
                Copy
              
            
          

Dans ce code, chaque `await` à l'intérieur de la boucle bloque toute exécution ultérieure jusqu'à ce que cette requête réseau spécifique soit terminée. Si vous avez 100 ID et que chaque requête prend 500 ms, le temps total sera d'un impressionnant 50 secondes ! C'est très inefficace car les opérations ne dépendent pas les unes des autres ; récupérer l'utilisateur 2 ne nécessite pas que les données de l'utilisateur 1 soient déjà présentes.

La solution classique : `Promise.all`

La solution établie à ce problème est `Promise.all`. Elle nous permet d'initier toutes les opérations asynchrones en même temps et d'attendre qu'elles soient toutes terminées.

            
async function fetchUserDetailsWithPromiseAll(userIds) {
  console.time("Promise.all Fetch");

  const promises = userIds.map(id => 
    fetch(`https://api.example.com/users/${id}`).then(res => res.json())
  );

  // Toutes les requêtes sont lancées de manière concurrente.
  const userDetails = await Promise.all(promises);

  console.timeEnd("Promise.all Fetch");
  return userDetails;
}

// Si chaque appel API prend 1 seconde, cela ne prendra plus qu'environ 1 seconde (le temps de la requête la plus longue).
fetchUserDetailsWithPromiseAll(ids);

            

              
                Copy
              
            
          

`Promise.all` est une amélioration considérable. Cependant, il a ses propres limites :

• Consommation mémoire : Il nécessite de créer un tableau de toutes les promesses à l'avance et conserve tous les résultats en mémoire avant de les retourner. C'est problématique pour les flux de données très volumineux ou infinis.
• Aucun contrôle de la contre-pression (backpressure) : Il lance toutes les requêtes simultanément. Si vous avez 10 000 ID, vous pourriez submerger votre propre système, les limites de débit du serveur ou la connexion réseau. Il n'y a pas de moyen intégré pour limiter la concurrence à, disons, 10 requêtes à la fois.
• Gestion d'erreur 'tout ou rien' : Si une seule promesse dans le tableau est rejetée, `Promise.all` rejette immédiatement, écartant les résultats de toutes les autres promesses réussies.

C'est là que la puissance des itérateurs asynchrones et des aides proposées brille vraiment. Ils permettent un traitement basé sur les flux avec un contrôle précis de la concurrence.

Comprendre les itérateurs asynchrones

Avant de pouvoir courir, il faut savoir marcher. Faisons un bref rappel sur les itérateurs asynchrones. Alors que la méthode `.next()` d'un itérateur normal renvoie un objet comme `{ value: 'une_valeur', done: false }`, la méthode `.next()` d'un itérateur asynchrone renvoie une Promesse qui se résout en cet objet.

Cela nous permet d'itérer sur des données qui arrivent au fil du temps, comme des morceaux d'un flux de fichier, des résultats d'API paginés ou des événements d'un WebSocket.

Nous utilisons la boucle `for await...of` pour consommer les itérateurs asynchrones :

            
// Une fonction génératrice qui produit une valeur chaque seconde.
async function* createSlowStream() {
  for (let i = 1; i <= 5; i++) {
    await new Promise(resolve => setTimeout(resolve, 1000));
    yield i;
  }
}

async function consumeStream() {
  const stream = createSlowStream();
  // La boucle s'arrête à chaque 'await' en attendant que la prochaine valeur soit produite.
  for await (const value of stream) {
    console.log(`Received: ${value}`); // Affiche 1, 2, 3, 4, 5, un par seconde
  }
}

consumeStream();

            

              
                Copy
              
            
          

Le changement de donne : la proposition des Aides d'itérateur

La proposition des Aides d'itérateur du TC39 ajoute des méthodes familières comme `.map()`, `.filter()` et `.take()` directement à tous les itérateurs (synchrones et asynchrones) via `Iterator.prototype` et `AsyncIterator.prototype`. Cela nous permet de créer des pipelines de traitement de données puissants et déclaratifs sans d'abord convertir l'itérateur en tableau.

Prenons l'exemple d'un flux asynchrone de relevés de capteurs. Avec les aides d'itérateur asynchrones, nous pouvons le traiter comme ceci :

            
async function processSensorData() {
  const sensorStream = getAsyncSensorReadings(); // Retourne un itérateur asynchrone

  // Syntaxe future hypothétique avec les aides d'itérateur asynchrones natives
  const processedStream = sensorStream
    .filter(reading => reading.temperature > 30) // Filtrer pour les températures élevées
    .map(reading => ({ ...reading, temperature: toFahrenheit(reading.temperature) })) // Convertir en Fahrenheit
    .take(10); // Ne prendre que les 10 premiers relevés critiques

  for await (const criticalReading of processedStream) {
    await sendAlert(criticalReading);
  }
}

            

              
                Copy
              
            
          

C'est élégant, efficace en mémoire (il traite un élément à la fois) et très lisible. Cependant, l'aide `.map()` standard, même pour les itérateurs asynchrones, est toujours séquentielle. Chaque opération de mappage doit se terminer avant que la suivante ne commence.

La pièce manquante : le mappage concurrent

La véritable puissance pour l'optimisation des performances vient de l'idée d'un map concurrent. Et si l'opération `.map()` pouvait commencer à traiter l'élément suivant alors que le précédent est encore en attente (`await`) ? C'est le cœur de l'exécution parallèle avec les aides d'itérateur.

Bien qu'une aide `mapConcurrent` ne fasse pas officiellement partie de la proposition actuelle, les briques de base fournies par les itérateurs asynchrones nous permettent d'implémenter ce modèle nous-mêmes. Comprendre comment le construire offre un aperçu profond de la concurrence en JavaScript moderne.

Construire une aide `map` concurrente

Concevons notre propre aide `asyncMapConcurrent`. Ce sera une fonction génératrice asynchrone qui prend un itérateur asynchrone, une fonction de mappage et une limite de concurrence.

Nos objectifs sont :

1. Traiter plusieurs éléments de l'itérateur source en parallèle.
2. Limiter le nombre d'opérations concurrentes à un niveau spécifié (par exemple, 10 à la fois).
3. Produire les résultats dans l'ordre où ils sont apparus dans le flux source.
4. Gérer la contre-pression naturellement : ne pas extraire les éléments de la source plus rapidement qu'ils ne peuvent être traités et consommés.

Stratégie d'implémentation

Nous allons gérer un pool de tâches actives. Lorsqu'une tâche se termine, nous en lancerons une nouvelle, en veillant à ce que le nombre de tâches actives ne dépasse jamais notre limite de concurrence. Nous stockerons les promesses en attente dans un tableau et utiliserons `Promise.race()` pour savoir quand la prochaine tâche est terminée, nous permettant de produire son résultat et de la remplacer.

            
/**
 * Traite les éléments d'un itérateur asynchrone en parallèle avec une limite de concurrence.
 * @param {AsyncIterable} source L'itérateur asynchrone source.
 * @param {(item: T) => Promise} mapper La fonction asynchrone à appliquer à chaque élément.
 * @param {number} concurrency Le nombre maximum d'opérations parallèles.
 * @returns {AsyncGenerator}
 */
async function* asyncMapConcurrent(source, mapper, concurrency) {
  const executing = []; // Pool des promesses en cours d'exécution
  const iterator = source[Symbol.asyncIterator]();

  async function processNext() {
    const { value, done } = await iterator.next();
    if (done) {
      return; // Plus d'éléments à traiter
    }
    
    // Démarrer l'opération de mappage et ajouter la promesse au pool
    const promise = Promise.resolve(mapper(value)).then(mappedValue => ({ 
        result: mappedValue,
        sourceValue: value
    }));

    executing.push(promise);
  }

  // Remplir le pool avec les tâches initiales jusqu'à la limite de concurrence
  for (let i = 0; i < concurrency; i++) {
    processNext();
  }

  while (executing.length > 0) {
    // Attendre que n'importe laquelle des promesses en cours se résolve
    const finishedPromise = await Promise.race(executing);

    // Trouver l'index et retirer la promesse terminée du pool
    const index = executing.indexOf(finishedPromise);
    executing.splice(index, 1);

    const { result } = await finishedPromise;
    yield result;

    // Puisqu'un emplacement s'est libéré, démarrer une nouvelle tâche s'il reste des éléments
    processNext();
  }
}

            

              
                Copy
              
            
          

            
// Aide pour simuler un appel API avec un délai aléatoire
function fetchUser(id) {
  const delay = Math.random() * 1000 + 500; // Délai de 500ms à 1500ms
  return new Promise(resolve => {
    setTimeout(() => {
      console.log(`Resolved fetch for user ${id}`);
      resolve({ id, name: `User ${id}`, fetchedAt: Date.now() });
    }, delay);
  });
}

// Un générateur asynchrone pour créer un flux d'ID
async function* createIdStream() {
  for (let i = 1; i <= 20; i++) {
    yield i;
  }
}

async function main() {
  const idStream = createIdStream();
  const concurrency = 5; // Traiter 5 requêtes à la fois

  console.time("Concurrent Stream Processing");

  const userStream = asyncMapConcurrent(idStream, fetchUser, concurrency);

  // Consommer le flux résultant
  for await (const user of userStream) {
    console.log(`Processed and received:`, user);
  }

  console.timeEnd("Concurrent Stream Processing");
}

main();

            

              
                Copy